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REMARKS/ARGUMENTS 

The Examiner is thanked for the performance of a thorough search and for the telephone 
interview conducted on November 15, 2006. 

By this amendment, Claims 1, 10, 18, 39, 48, and 56 have been amended. Claims 5, 14, 
21, 43, 52, and 59 have been cancelled. No claims have been added. Hence, Claims 1-4, 6-13, 
15-20, 39-42, 44-51, and 53-58 are pending in the application. 

The amendments to Claims 1, 10, 18, 39, 48, and 56 as indicated herein do not add any 
new matter to this application. Furthermore, the amendments made to Claims 1, 10, 18, 39, 48, 
and 56 as indicated herein have been made to exclusively improve clarity of the claims and not 
for the purpose of overcoming alleged prior art. For example, Claims 1, 10, 18, 39, 48, and 56 
have been amended to recite what types of file operations may be performed on the file that 
represents a resource. 

I. SUMMARY OF TELEPHONE INTERVIEW 

The Examiner and the Examiner's supervisor held a telephone interview on November 
15, 2006 with Applicant's representatives Daniel D. Ledesma and Christopher J. Palermo. 

The parties discussed the Office Action mailed September 21, 2006, in which Claims 1- 
21 and 39-59 were rejected under 35 U.S.C. § 102(b) as allegedly anticipated by U.S. Patent No. 
6,202,066 to Barkley et al. ("Barkley"). The Examiner and representatives of the Applicants 
did not reach an agreement. 

II. ISSUES RELATING TO PRIOR ART 

Claims 1-21 and 39-59 stand are rejected under 35 U.S.C. § 102(b) as allegedly 
anticipated by Barkley. The rejection is respectfully traversed. 
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A. CLAIM 1— BARKLEY 

An anticipation rejection under 35 U.S.C. § 102 is overcome by a showing that the 
applicant's claims include at least one feature that is not shown, described or taught in the cited 
prior art reference, explicitly or by inherency. 

The Federal Circuit ruled that anticipation "requires the presence of a single prior art 
disclosure of all elements of a claimed invention arranged as in the claim.. .. A prior art 
disclosure that 'almost' meets that standard does not 'anticipate.'" Connell v. Sears, Roebuck & 
Co. 722 F.2d 1542, 1548 (Fed. Cir. 1893). 

Barkley does not teach or suggest the elements of Claim 1 as arranged in the claim, 

much less all elements of Claim 1. Present Claim 1 recites: 

A method for controlling access to a resource, the method comprising the steps of: 
creating and storing in a filesystem of an Operating System a file that represents the 
resource; 

receiving user-identifying information from a user requesting access to the resource, 
wherein the user-identifying information comprises a role associated with the 
user, wherein the role is determined from a user identifier uniquely associated 
with the user and from a group identifier associated with a group that includes 
the user; 

receiving a resource identifier associated with the resource; 

creating an access identifier based on the user-identifying information and the 

resource identifier, wherein the access identifier is formatted as a file attribute 
that is used by the Operating System to manage file access; 

calling the Operating System to perform a file operation on the file by providing the 
access identifier to the Operating System to attempt access to the file; and 

granting the user access to the resource when the Operating System call successfully 
performs the file operation; 

wherein the file operation on the file representing the resource is selected from a group 
consisting of opening the file, closing the file, deleting the file, reading from the 
file, writing to the file, executing the file, appending to the file, reading a file 
attribute, and writing a file attribute, (emphasis added) 

In an embodiment, resources may be a software application, software application 

message, server, router, switch, file, directory, etc. (Specification, paragraphs 27 and 28). A file 

is created and stored in a filesystem of an Operation System. The file represents the particular 
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resource. Subsequently, user-identifying information is received from a user who is requesting 
access to that resource. A resource ID associated with the resource is also received, e.g., from 
the user. Subsequently, an access ID is created based on the user-identifying information and 
the resource ID. The access ID is formatted as a file attribute that is used by the Operating 
System to gain access to the file. The Operating System is then called to perform an operation 
(e.g., open the file, write to the file, delete the file) on the file that represents the resource. This 
is done by providing the access ID to the Operating System to attempt access to the file. The 
user is granted access to the particular resource when the Operating System call successfully 
performs the operation. 

Because Operating Systems calls are used to attempt access to a file, a complex security 
mechanism is avoided and application software developers are not required to learn a specific 
API and to write code against it (see Specification, paragraph 3). Claim 1 uses the filesystem of 
an Operating System to manage access to files. The OS filesystem is one of the most well- 
known and easy to write code systems in a computer system (see Specification, paragraphs 4, 7, 
and 8). 

In contrast, Barkley teaches an OAT implementation that serves "as a highly 
sophisticated mechanism for maintaining the conventional ACLs of all the objects assigned to 
the OAT." (col. 8, lines 29-31). An OAT is an object that associates individuals or groups with 
permissions with one or more objects or resources (see col. 6, lines 19-26). An application 
software developer must learn the "highly sophisticated [OAT] mechanism" in order to manage 
access to resources. 

Due to this significant difference, Barkley fails to teach or suggest all the features of 
Claim 1. 
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1. Barkley fails to teach or suggest "calling the Operating System to perform a file 
operation on the file " 

The Office Action contends that col. 8, lines 25-38 of Barkley discloses this step. 
However, that portion of Barkley states that a management software tool (i.e., called "RGP- 
Admin") manages Object Access Types (OATs) and writes permissions and users associated 
with each object to access control lists (col. 8, lines 25-28). RGP-Admin does not perform a 
file operation on a file. Barkley' s references to the Windows NT operating system are only 
referring to the environment in which the RGP-Admin management software tool executes. 
Indeed, it must be the RGP-Admin tool, not the Windows NT operating system, that is called to 
perform operations on OATs (i.e., the alleged files) (see col. 8, lines 8-38) since OATs are not 
an inherent part of an Operating System. A special API must be used to access one or more 
OATs associated with a resource. Therefore, the operation performed on an OAT cannot be 
a file operation. 

The entire reference of Barkley fails to teach or suggest that the Windows NT operating 
system is called to perform an operation on an OAT to gain access to a resource, much less a 
file operation. In fact, the entire portion of Barkley does not even state that an operation is 
performed on an OAT to gain access to a resource. Barkley merely states that access is 
permitted to a resource depending on the OAT associated with that resource. Thus, Barkley 
fails to teach that an Operating System performs an operation on a file, as claimed. 

In response to this argument, the Office Action cited the Background section of Barkley 
(col. 2, lines 35-54) for disclosing this step of calling the Operating System to perform an 
operation on a file. Previously, and in the telephone interview, the Examiner equated the "file" 
of Claim 1 to the OAT of Barkley. Thus, that cited portion of Barkley would have to state that 
the Windows NT operating system is called to perform an operation on an OAT. However, this 

Seq.No. 7841 19 



Docket No. 50325-0805 

is not the case. Even if the Background section of Barkley taught that an operating system is 
called to perform an operation on a file, the invention of Barkley teaches away from that 
approach by teaching an OAT implementation for managing access to a resource. Furthermore, 
the files referred to in the cited portion of the Background section are the actual resources 
whose access is sought, and not files that represent those resources, as claimed. 

The practice of citing portions of the Background section of a reference with the 
Detailed Description section of the reference is problematic. The Background section of an 
application is given to present a problem with current technologies and the rest of the 
application effectively teaches away from those current technologies. Thus, it is inappropriate 
to cite portions of a Background section from which the rest of the cited reference teaches 
away. 

2. Barkley fails to teach or suggest the access identifier as claimed 
The Office Action cites col. 2, lines 23-26 and col. 4, lines 59-60 as disclosing "creating 
an access identifier based on the user-identifying and the resource identifier, wherein the access 
identifier is formatted as a file attribute that is used by the Operating System to manage file 
access", as recited in Claim 1. Again, the Office Action inappropriately combines portions of 
the Background section of Barkley with portions of the Detailed Description of Barkley that 
teach away from the approach described in the Background section. 
The cited portions merely state: 

"object security attributes are usually kept with the object (e.g., in the header of a file) 
and the object resides in (or a resource is accessed through) a single server"; and 

"OATs can be created, edited, deleted, and assigned to or removed from objects. Each 
OAT thus defines an access control specification." 
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Barkley states that one of the benefits of an OAT approach is that OATs are kept 
separate from the resource, where as the object security attributes of a prior art approach are 
kept with the resource. It is not clear from these cited portions what could be analogized with 
the access identifier of Claim 1 . Barkley is silent as to any such access identifier that is created 
based on user-identifying information and a resource identifier, and is formatted as a file 
attribute. 

Furthermore, the OAT approach described in Barkley is silent as to anything relating to 
an access identifier, much less an access identifier that is formatted as a file attribute. One 
reason that Barkley is silent as to this matter is because Barkley fails to provide an example of 
how a user is granted access to a resource that is associated with an OAT. No example of given 
that describes how an OAT is accessed and read to determine whether a user has access to a 
resource associated with the OAT. 

Based on the foregoing, Barkley fails to teach or suggest all the features of Claim 1 . 
Therefore, removal of the 35 U.S.C. § 102(b) rejection and reconsideration of Claim 1 is 
respectfully requested. 

B. CLAIMS 10, 18, 39, 48, AND 56 

The Office Action stated the same reasons in rejecting Claims 10 and 18 to those in 
rejecting present Claim 1 . Also, Claims 39, 48 and 56 recite features discussed above that 
make Claim 1 patentable over Barkley. Therefore, for at least the same reasons set forth above 
by the Applicant in connection with present Claim 1, it is respectfully submitted that each of 
Claims 10, 18, 39, 48 and 56 is patentable over Barkley. 
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C. DEPENDENT CLAIMS 

The dependent claims not discussed thus far are dependent claims, each of which 
depends (directly or indirectly) on one of the independent claims discussed above. Each of the 
dependent claims is therefore allowable for the reasons given above for the claim on which it 
depends. In addition, each of the dependent claims introduces one or more additional 
limitations that independently render it patentable. However, due to the fundamental 
differences already identified, to expedite the positive resolution of this case, a separate 
discussion of those limitations is not included at this time. The Applicant reserves the right to 
further point out the differences between the cited art and the novel features recited in the 
dependent claims. 

II. CONCLUSIONS & MISCELLANEOUS 

For the reasons set forth above, it is respectfully submitted that all of the pending claims 
are now in condition for allowance. Therefore, the issuance of a formal Notice of Allowance is 
believed next in order, and that action is most earnestly solicited. 

The Examiner is respectfully requested to contact the undersigned by telephone if it is 
believed that such contact would further the examination of the present application. 

Please charge any shortages or credit any overages to Deposit Account No. 50-1302. 



2055 Gateway Place, Suite 550 

San Jose, CA95110 

(408)414-1080 

Date: November 17, 2006 

Facsimile: (408) 414-1076 
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Respectfully submitted, 

HICKMAN PALERMO TRUONG & BECKER LLP 




Daniel D. Ledesma 
Reg. No. 57,181 



